Meta Data Security

Säkerhet på metadata (SPM)

Säkerhet på metadata (förkortat SPM) är en teknik som gör det möjligt att kontrollera behörigheter på XML-dokument (EPT-dokument) i CS genom relationer/klassificeringar av innehållet i XML-dokumenten. Innebörden är att de effektiva behörigheterna för ett dokument kan bero på INNEHÅLLET i dokumentet, förutom de behörigheter som dokumentet och den kategori där dokumentet ligger i, har försatts med. De effektiva behörigheterna är alltså en kombination av informationen i dokumentet och de vanliga behörigheterna satta på dokumentet eller den kategori där dokumentet ligger.

Skillnaden mot att sätta behörigheter på kategorier eller dokument, på traditionellt sätt, är att behörigheterna för dokumentet slår igenom oavsett var i informationsstrukturen (IFS) dokumenten ligger – alltså oavsett i vilken enhet eller kategori dokumentet ligger i. Istället styrs behörigheterna från innehållet i dokumentet (dvs. hur det är klassificerat). Det är alltså enklare att styra behörigheter för dokument i de fall behörigheterna skall ändras på många olika kategorier eller dokument i CS.

Om en webbplats är försedd med olika typer av dokument, exempelvis nyheter, protokoll och artiklar, och dessa dokument är klassificerade avseende exempelvis Ort och Typ (märks upp genom lookup-kategorier), kan de effektiva behörigheterna genom SPM styras genom behörigheter kopplade till de olika orterna och typerna. Alla dokument kopplade till exempelvis orten Visby kan förses med en viss typ av behörighet - oavsett dokumenttyp. Behörigheterna styrs via klassificeringsdokumentet "Visby" istället för dokumentet självt.

Utan SPM

För större organisationer med många ”enheter”, ”avdelningar” eller motsvarande indelningar, finns det möjlighet att lagra dokument i samma kategori i CS. Det finns vissa fördelar med detta, bland annat att XML-sökningar kan användas (då dokumenten ligger samma kategori i CS), det är enklare att göra förändringar (ex ny indexering av fält behöver bara ske på en kategori). Detta har naturligtvis varit möjligt även innan SPM-tekniken fanns, men nackdelen var att det innebar att alla användare kunde se alla dokument i kategorin i Content Studio administrativa gränssnitt. Enda möjligheten att gömma dokumenten var att sätta behörigheter direkt på dokumenten. Nackdelen med detta är dock att det är svårt att på ett enkelt sätt ändra behörigheten på samtliga dokument tillhörande enhet x.

Alternativet att bygga upp en IFS (utan SPM) med många enheter/kategorier kan alltså ibland vara svårt, exempelvis för organisationer med tusentals enheter. Resultatet kan bli en lösning som kräver alltför mycket underhåll vid indexering, nyutveckling eller ändring av behörigheter.

Med SPM

SPM innebär att dokument kan lagras i en och samma mapp, men inte nås, ses eller redigeras av andra personer än de som har erforderliga behörigheter. Det spelar alltså ingen roll att kategorin innehåller tusentals dokument – användaren kommer bara att ha åtkomst till de dokument som denne har behörighet till.

Att sätta upp säkerhet på metadata

Beroende på hur organisationen är organiserad, vilka krav som ställs på behörigheter och funktionalitet passar olika IFS:er mer eller mindre bra. Det kan ofta vara fördelaktigt att dela upp IFS:en i två grundnivåer: Admin och Content. Content kommer att innehålla data som skapas av redaktörer och Admin innehåller kod, formulär och mallar som hanteras av administratören. Uppdelningen på dessa två grundnivåer gör det enklare att sätta behörigheter, dvs. begränsa vilka personer/grupper som har behörigheter att göra förändringar mallar etc.

Exempel på IFS

Nedan visas ett exempel på hur informationsstrukturen kan sättas upp, i detta fall för Nyheter som skall kunna hanteras av ett stort antal Avdelningar (kursiva rader nedan avser dokument, icke kursiva rader avser kategorier).

Admin (här lagras all programkod, formulär och mallar).
 Moduler
  Nyheter
   Redigeringsformulär
    Redigeringsformulär Nyheter
   Presentationsmallar
   Infogat
 Delade resurser
  Avdelningar
   Redigeringsformulär Avdelningar

Sv (här lagras data som skapas av redaktörer eller administratörer)
 Moduler
  Nyheter
   Nyhet 1 från avdelning A (nyhet som skapats av person på avd 1)
   Nyhet 2 från avdelning B
   Nyhet 3 från avdelning C
   Nyhet 4 från avdelning D
   Nyhet x från avdelning y
 Lookup (här lagras dokument som används vid klassificering)
  Avdelningar (här lagras de olika avdelningarna – ett dokument per avdelning).
   Avdelning A
   Avdelning B
   Avdelning C
   Avdelning D
   Avdelning y   

Skapa redigeringsformulär för lookup-kategori(er)

Den organisatoriska uppdelningen mellan olika enheter/avdelningar sker genom att sätta upp en EPT-lösning innehållande x stycken olika enheter/avdelningar i så kallade lookup-kategorier.

Redigeringsformulär för lookup-kategorierna behöver upprättas och förslagsvis läggs de under Admin/Delade resurser/Avdelningar. Redigeringsformuläret behöver i stort sett bara innehålla rubrik (Namn på avdelningen).

Skapa redigeringsformulär för datakategorier

De redigeringsformulär som används för att skapa data, exempelvis Nyheter, behöver förses med en eller flera kontroller som klassificerar innehållet, dvs. kopplar det till en eller flera organisatoriska enheter. I nyhetsexemplet i detta dokument skulle kopplingen ske mot Avdelning.

AS-komponenter och SPM

Kopplingen mellan data och dess klassificering sker i de flesta fall genom en eller flera dropdown-listor som skapas med AS-komponenten "List Filtered Documents In Dropdown Advanced". För att listan bara ska fyllas med de avdelningar som användaren har rätt att skapa information för måste komponenten aktiveras för att kontrollera behörighet att läsa. "Check security" och "Check for read permission" är de parametrar som aktiverar en kontroll av användarens behörighet att läsa av samtliga dokument i dropdown-listan. Saknas läsbehörighet kommer alltså listan inte att fyllas med dokumentet. I nyhetsexemplet i detta dokument kan det kopplade fältet ges namnet DepartmentID. Detta EPT-fält kommer att innehålla ID-numret på den Avdelning som dokumentet kopplas till. DepartmentID måste indexeras innan SPM kommer att kunna aktiveras.

Om andra komponenter än "List Filtered Documents In Dropdown Advanced" önskas användas kan godtycklig inputkontroll användas. För att aktivera SPM skall attributet cssec sättas till 1 (cssec=”1”). För samtliga SPM-fält måste en indexering ske.

Det är även möjligt att koppla FLERA dokument (organisatoriska enheter) med hjälp av SPM. Detta förutsätter att kopplingen sker i ett fält innehållande kommaseparerade ID-nummer. Den effektiva behörigheten som krävs för att läsa/skriva dokument, kommer att vara resultatet av sammanslagningen av samtliga behörigheter, se nedan.

Tänk på att om ett dokument märks upp att tillhöra exempelvis Stockholm OCH Göteborg, kommer det att krävas behörigheter till BÅDA dessa enheter för arbeta med dokumentet, exempelvis skrivbehörighet. Det går alltså inte att separera uppmärkning från behörigheter om inte dubbla klassificeringsprinciper används (SPM+annan).

Uppmärkning genom infogade sidor

Det är vanligt att olika redigeringsformulär använder liknande funktionalitet för att exempelvis märka upp eller klassificera innehåll. Det vanligaste sättet är då att skapa en s.k. include som innehåller de kontroller som behövs, exempelvis EPT-buttons och en dropdown-lista med olika organisatoriska enheter. Detta är också möjligt i de fall SPM används.

Eftersom SPM upprättas och kopplas genom attribut i schemat, som i sin tur renderas från redigeringsformulärets HTML/XHTML-kod inklusive samtliga infogade dokument, i kombination med att cssec är ett attribut som inte FINNS i ett godkänt innehåll i doctyp XHTML, måste alltså samtliga includes relaterade till SPM att vara skapade med doctyp HTML Transitional.

Aktivera säkerhet på metadata

På den kategori där SPM skall användas MÅSTE egenskapen Säkerhet på metadata (Meta data security) aktiveras, dvs. sättas till något följande alternativ:

• På = endast vid läsning av dokument, EJ i listor i Content Studio administrativa gränssnitt. Bör användas om möjligt.
• På, även i listor = vid läsning OCH listning av dokument i Content Studio administrativa gränssnitt. Kräver mer kraft av servern eftersom de effektiva behörigheterna på varje enskilt dokument enumereras runtime.

Indexering och SPM

De fält som i redigeringsformuläret används för att koppla dokument med SPM måste indexeras INNAN data (nyheter i detta fall) skapas. Det är vid lagring av dokument som kopplingstabellerna (säkerhetstabeller) underhålls med olika korsreferenser mellan metadatadokument och dokument.

Schema och SPM

Det schema som renderas av CS kommer att förses med attribut som anger att ett visst fält används vid SPM. Exempel:

<ElementType name="DepartmentID" content="textOnly" default="4457">
   <AttributeType name="ElementLength" default="1" />
   <AttributeType name="cssec" default="1" />
   <attribute type="ElementLength" />
   <attribute type="cssec" />
</ElementType>

Om doctyp XHTML används kommer det godkända och sparade innehållet INTE att innehålla det nödvändiga cssec attributet i redigeringsformuläret. Detta betyder i sin tur att includes med doctyp XHTML inte kan användas i SPM-sammanhang. Använd istället HTML Transitional för includes.

Behörigheter med SPM

För att SPM skall fungera måste både behörigheterna i lookup-kategorierna (i vårt exempel kategorin Avdelningar) och i datakategorin (i vårt exempel kategorin Nyheter) vara korrekta.

Tänk på att användargruppen Administrators är en s.k. specialgrupp i CS. De användare som ingår i denna grupp kommer INTE att uppleva effekten av uppsatt SPM på korrekt sätt eftersom Administrators har högre behörigheter än vad som visas i CS. För att testa uppsatt SPM rekommenderas att logga in med en användare som ingår i någon av de användargrupper som SPM konfigureras för, exempelvis Nyhetsredaktörer.

Lookup-kategorier

För de kategorier som används för klassificering av dokument, exempelvis Avdelningar skall följande säkerhetsinställningar göras:

1. Stänga av arv
2. Lägg till behörigheten läsa/lista, men endast på denna behållare
3. För de dokument (avdelningar) som AD-grupp X, eller användare Y skall se i dropdown-listan, sätt behörigheten Read.
4. Säkerhet på metadata: för de dokument (avdelningar) som AD-grupp X, eller användare Y, ska ha en viss behörighet för, exempelvis skapa, modifiera, radera publicera, sätt dessa behörigheter.

För administratörer eller användare som skall kunna skapa/ta bort/redigera lookup-kategorier, exempelvis Avdelningar, sätts behörigheterna upp på vanligt sätt.

Datakategorier

För de kategorier som används för att lagra data/dokument, exempelvis Nyheter, behöver följande säkerhetsinställningar göras:

1. De säkerhetsgrupper eller användare som skall ha behörighet att skapa nyheter måste ha samma behörigheter som utan SPM, dvs. exempelvis Läsa/lista, skapa, ta bort, publicera osv. Alltså samma behörigheter som utan SPM. Arvet behöver inte korrigeras.

Teknik - så fungerar SPM

1. API:erna kontrollerar att användaren har läsa/lista på själva kategorin.
2. Om Ja på fråga 1: är SPM aktiverat på kategorin?
3. Om Ja på fråga 2, gå till 4. Om Nej på fråga 2 – returnera listan utan ytterligare säkerhetskontroller.
4. Kontrollera behörigheten på varje enskilt dokument i listan:
5. För varje dokument: kontrollera behörigheten på alla kopplade dokument (kopplade till SPM)
6. Slå samman behörigheterna för respektive rättighet. Saknas en behörighet på något av de kopplade dokumenten, eller Neka behörighet är uppsatt: avbryt säkerhetskontrollen och returnera Icke behörighet. Exempel: Antag att API:erna skall beräkna om användaren har behörigheten Read och att det är 3 kopplade dokument:
   • Dokumentet i sig själv: Read
   • Kopplat dokument 1: Read
   • Kopplat dokument 2:
   • Kopplat dokument 3: Deny Read
7. I detta fall skulle den effektiva behörigheten på dokumentet vara Deny Read, av två anledningar: Dels saknas behörigheten i c) och dels nekas användaren (direkt eller indirekt) behörigheten i d). API:erna avbryter säkerhetskontrollen redan i c).

Steg 5-6 upprepas för hela dokumentlistan.

Prestanda

SPM påverkar inte prestandan på webbplatsen i någon större utsträckning. När SPM används sker extra säkerhetskontroller när ett dokument efterfrågas, men dessa anrop tar väldigt kort tid att utföra. Däremot, i administrationsgränssnittet för Content Studio, och där i dokumentlistor med SPM-inställningen "På även i listor", påverkas prestandan dramatiskt. Orsaken är att denna inställning gör att Content Studio behöver utföra säkerhetskontroller på samtliga dokument i kategorin innan resultatet kan presenteras - vilket naturligtvis innebär en större belastning än att endast returnera en sida med dokument. Inställningen för SPM, "På även i listor", är därför inte rekommenderad på en sajt med många redaktörer.

Prestandatester har gjorts för att undersöka hur SPM påverkar prestandan på en webbplats och i det administrativa gränssnittet i Content Studio. Förutsättningar prestandatestet:
En dokumentkategori med 2500 dokument (webbsidor) kopplade till en annan dokumentkategori innehållande 500 "orter". Användare som användes under testerna hade läsbehörighet till en (1 st) ort och därigenom 5 webbsidor. Som testverktyg användes Microsoft Application Stress från en klient och med en tråd. Mer om testverktyget finns i kapitlet Performance Optimization.

Det första testet listade 30 dokument i kategorin med webbsidor där SPM på i listor var påslaget. Testet ledde till 0,35 anrop/sekund till webbservern. Samma test genomfördes med SPM avstängt och det gav 21 anrop/sekund (SPM-på ger samma resultat som SPM-av eftersom ingen av dessa påverkar dokumentlistor). SPM på i listor är med andra ord 60 gånger långsammare (med givna testförhållanden) än SPM avstängt.

Ett annat test utfördes för att avläsa hur SPM påverkade prestandan på webbplatsen. Testet utfördes dels med SPM aktiverat, och dels med SPM avstängt (SPM på i listor påverkar inte prestandan ute på webbplatsen). SPM aktiverat resulterade i 95 anrop/sekund, medan SPM avaktiverat resulterade i 97 anrop/s - en marginell skillnad alltså.